Dynamic systems are characterized by the fact that their behaviors change over time and are representative of many real-world systems. The dynamic systems are typically modeled as sets of differential, difference, and/or algebraic equations. At any given instant of time, these equations may be viewed as relationships between the system's output response (“outputs”), the system's input stimuli (“inputs”) at that time, the current state of the system, the system parameters, and time. The state of the system may be thought of as a numerical representation of the dynamically changing configuration of the system. For instance, in a physical system modeling a simple pendulum, the state may be viewed as the current position and velocity of the pendulum. Similarly, a signal-processing system that filters a signal would maintain a set of previous inputs as the state. The system parameters are the numerical representation of the static (unchanging) configuration of the system and may be viewed as constant coefficients in the system's equations. For the pendulum example, a parameter is the length of pendulum and for the filter example; a parameter is the values of the filter taps.
There are four common types of mathematical models used in the study of dynamic systems. The first type of mathematical model describes systems using ordinary differential equations (ODEs). This type of dynamic system specifies a set of two equations: Output and Derivative. The Output equation facilitates the computation of the system's output response at a given time instant as a function of its inputs, states, parameters, and time. The Derivative equation is an ordinary differential equation that allows the computation of the derivative of the states at the current time as a function of the inputs, the states, parameters, and time. This class of models is suitable for systems in which it is important to track the system response as a continuous function of time. Such continuous-time systems are commonly representative of physical systems (mechanical, thermal, electrical). For simple systems, it may be possible to use the Output and Derivative equations to obtain a closed-form solution for the output response y(t). But in most complex real world systems, the response of the system is obtained by integrating the states through numerical means.
The definition of an ODE used herein encompasses both implicit and explicit differential equations. The class of ordinary differential equations may require additional equations to define the system being modeled. For example, equations called projections may be required to impose constraints on the differential variables (e.g., states X1 and X2 must fall on the manifold defined by x12+x22=25). These constraints can be either applied as a secondary condition or a coupled condition to the differential equation. Although systems including the projections may conventionally no longer qualify as an ODE; they are included here to simplify the categories of systems. Another example is the use of a Jacobian equation that defines partial derivatives with respect to the independent and/or differential variables. The Jacobian equation is typically used when obtaining a linear approximation of a non-linear model or an overall linear model of a set of equations. Jacobian equations are required for some forms of numerical integration, for producing the linear model once the model has reached its steady state operating point, etc. The Output and Derivatives equations may be extended to define other relationships for the block. For example, the Output equation may help manage its states by defining a relationship where it resets the state back to a known quantity at a specific point in time or when a specific condition is seen.
Another type of mathematical model describes systems using difference equations. This type of the dynamic system specifies a set of two equations: Output and Update. The Output equation facilitates the computation of the system's output response at a given time instant as a function of the inputs, states at some previous time, parameters, and time. The Update equation is a difference equation that allows the computation of the states at the current time as a function of the inputs, states at some previous time, parameters, and time. This class of models is suitable for systems in which it is important to track the system response at discrete points in time. Such discrete-time systems are commonly representative of discrete-time control and digital signal processing systems. For simple systems, it may be possible to use the Output and Update equations to obtain a closed-form solution for the output response y(t). But in most complex real world systems, the response of the system is solved through recursion. The Output and Update equations are applied repeatedly to solve for the system response over a period of time.
An additional type of mathematical model describes systems using algebraic equations. This type of the dynamic system uses an algebraic equation that needs to be solved at each time to obtain the outputs. While simple systems may allow one to obtain a closed-form solution for the system inputs and outputs, practical algebraic equations may best be solved iteratively using a numerical method involving both perturbations and iterations. Algebraic equation solving techniques used in the context of dynamic system modeling are discussed in greater detail below.
A fourth type of mathematical model is a composite system that has components that fall into the three types of models discussed above. Most complex real-world system models fall into this category. This class of systems has Output, Derivative, Update, and potentially other equations. Solving for the output response of such systems requires a combination of the solution approaches discussed for all of the classes above. One example of a composite system is one described by differential-algebraic equations (DAEs) which contain both differential equations and algebraic equations.
Grouped within the composite class of systems are many extensions involving relationships (equations) defined in terms of both outputs and state. For example, one can define a limited integration relationship for a differential variable. This relationship requires a set of equations that consists of the Output equation, an Update equation, a Derivative equation, and a Zero Crossing equation. The Zero Crossing equation defines the points in time where the upper and lower limits of the limited integration occur. Another example of an extension is the notion of Enable and Disable equations that define relationships among states or signals when parts of a system are activated and deactivated during execution.
Inherent in the four classes of systems (ODE, difference equations, algebraic equations and composite) is the notion of system sample time. The sample-time is the time interval at which the inputs, state, or outputs (collectively referred to as the results) of the system are traced as time progresses. Based on sample times, a system can be described as a discrete-time system, continuous-time system and hybrid system.
A discrete-time system is a system in which the evolution of the system results is tracked at finite intervals of time. In the limit as the interval approaches zero, the discrete-time system becomes a continuous-time system. The intervals of time may be periodic or non-periodic. Sometimes, non-periodic rate systems are referred to as nonuniform-rate systems meaning that there is no periodic rate at which the response can be tracked. Nonuniform-rate systems can fall into the class of composite systems where an additional equation (GetTimeOfNextVarHit) defines when in the future the other equations associated with the system should be evaluated. A continuous-time system is a system in which the evolutions of the system results are continuously changing. Continuous-time signals change during numerical integration (minor time steps). An example of a continuous-time system is one described by an ODE. There can also be algebraic or composite continuous-time systems. A hybrid system is a system with both discrete-time and continuous-time elements.
If a system has only one sample time, it is said to be single-rate. If a system has multiple sample times, it is said to be multi-rate. Multi-rate systems can be evaluated (executed) using either a single-tasking form of execution or a multi-tasking form of execution. When multi-tasking execution is used, it conforms to rate monotonic scheduling principles as defined by Liu, C. L., and Layland, J. W. Scheduling Algorithms for Multiprogramming in a Hard-Real-Time Environment. ACM 20, 1 (January 1973), 46-61. Systems may also be categorized by the type of numerical integration solver being used. A fixed-step system is one that uses a fixed-step solver. Fixed-step solvers often use explicit methods to compute the next continuous state at fixed periodic intervals of time. A variable-step system is one that is using a variable-step solver. A variable-step solver can use either implicit or explicit methods to compute the next continuous state at non-periodic intervals of time. Generally, variable-step solvers use a form of error control to adjust the interval size such that the desired error tolerances are achieved.
An execution context (EC) is a data structure for a group of blocks that all execute when an associated pre-condition is satisfied. Blocks may inherit and define ECs, just as prior modeling software allowed inheriting and defining sample times in blocks. EC information may also be propagated throughout the block diagram allowing blocks to opt into or out of an EC's grouping. ECs are not confined to time-based block diagrams and may be extended to provide execution efficiency in the context of data flow and other block diagram models.
An EC may be defined to be a hierarchical partitioning of a block diagram into groups of blocks that execute only when a pre-condition is fulfilled. An EC may be viewed as the generalization of the notion of a conditionally executed (CE)-Subsystem; the generalization being removal of the restriction that the execution pre-condition is associated strictly with a subsystem. Similar to CE-Subsystems, ECs can be nested within each other to obtain arbitrary levels of hierarchy. Unlike a CE-Subsystem, which imposes the implicit restriction that blocks have to live within the Subsystem to execute in accordance with a pre-condition, an EC may be associated with any block as an explicit attribute (similar to sample times).
Each block in the block diagram is parented by one of the ECs created in the block diagram. A block's EC information may be thought of as a block attribute similar to its sample time. A particular block executes only when the pre-condition of its parent EC is satisfied, activating the EC. Furthermore, the block executes in accordance to its sample time once its parent EC has been activated.
The EC can be created and associated with individual block diagram elements and/or subsystems. The EC allows execution of the associated element or subsystem upon satisfaction of a specified pre-condition. The EC may be inherited by other elements and subsystems in the block diagram and propagated programmatically throughout the block diagram. The use of the EC allows for efficient code generation and block diagram execution, as well as supporting modular design concepts.
The EC technology is described in more detail in a pending application entitled “A SYSTEM AND METHOD FOR USING EXECUTION CONTEXTS IN BLOCK DIAGRAM MODELING” (U.S. patent application Ser. No. 10/414,644) filed on Apr. 16, 2003.
In practice, except for the most basic systems, mathematical models for dynamic systems involve a complex set of mathematical transformations applied in some prescribed manner with the outputs of some transformations forming the inputs of others. Each elemental transformation may be viewed in isolation as a simple dynamic system falling into one of the categories listed above. Therefore, a complex dynamic system may be modeled as an interconnection of various simple dynamic systems. A schematic representation of such an interconnection that has evolved over the years is the block diagram. Such block diagram models have now become a standard means in textbooks, design papers, journal articles, and specifications to communicate the details of a dynamic system's behavior.
A block diagram model of a dynamic system is represented schematically as a collection of blocks interconnected by lines that represent signals. A signal represents the input and output of a dynamic system. Each block represents an elemental dynamic system. A line emanating at one block and terminating at another signifies that the output of the first block is an input to the second block. Each distinct input or output on a block is referred to as a port. Signals correspond to the time-varying quantities represented by each line connection and are assumed to have values at each time instant. The source block of a signal writes to the signal at a given time instant when its system equations are solved. The destination blocks of this signal read from the signal when their system equations are being solved. The block diagram includes a plurality of blocks, lines and ports that are interconnected. Those skilled in the art will recognize that the term “blocks” does not refer exclusively to elemental dynamic systems but may also include other modeling elements that aid in readability and modularity of block diagrams.
The theory of Digital Signal Processing (DSP) focuses on modeling signals as sequences of samples. This view naturally fits into the time-based block diagram paradigm by mapping the samples u[n] to discrete-time points u(tk). This adds the benefit of being able to model the interaction between DSP systems and other classes of time-based systems, e.g. continuous and/or discrete-time control systems.
Put another way, block diagram models are time-based relationships between signals and state variables representative of a dynamic system. The solution (computation of system response) of the model is obtained by evaluating these relationships over time, where time starts at a user-specified “start time” and either ends at a user-specified “stop time” or based on evaluating a criterion that may involved model quantities. At each time step these relationships are evaluated. Signals represent quantities that change over time, and these quantities are defined for all points in time between the block diagram's start and stop time. The relationships between signals and state variables are defined by sets of equations represented by blocks. These equations define a relationship between the input signals, output signals, state, and time. Inherent in the definition is the notion of parameters, which are the coefficients of the equations.
The block diagrams are not exclusively used for representing time-based dynamic systems but also for other models of computation. For instance, flow-charts are block diagrams used to capture process flow and are not generally suitable for describing dynamic system behavior. Data flow block diagrams are block diagrams that describe a graphical programming paradigm where the availability of data (often thought of as tokens) is used to initiate the execution of blocks, where a block represents an operation and a line represents execution dependency describing the direction of data flowing between blocks. As used herein, the term block diagrams means time-based block diagrams used in the context of dynamic systems except as otherwise noted.
Execution of a block diagram generally proceeds in a couple of stages including compilation, initialization and execution or simulation loops. The compilation stage incorporates library blocks into the block diagram, propagates signal dimensions, data types, and sample times, evaluates parameters, determines block sorted orders, and allocates memory for output/input buffers, states, parameters, etc. The initialization stage executes Model Start method, which in turn calls each block's Block Start method. In the Block Start method, blocks do various tasks, such as checking parameters and writing out the initial output signals. The initialization stage then calls the Model Initialize method, which calls each block's Block Initialize method. In this method, the state of the block is initialized. After the initialization stage, the block diagram enters the execution or simulation loop, where each pass through the loop is referred as an execution or simulation step. During each of these steps, various block methods, such as Block Outputs method, Block Derivatives method and Block Update method, are invoked to compute outputs, derivatives and states for each block. The simulation loop continues until the final time of the execution is reached or a termination request is issued.
In the conventional initialization stage, blocks in a block diagram fall into one of two types. The first type is the blocks that know their output prior to model execution and can write out an initial output value in the initialization stage. For example, in Simulink® the Constant block knows it output prior to model execution and writes out a specified value in its Block Start method. The second type is the blocks that don't explicitly know their output prior to model execution and thus can't write out an initial output value before simulation starts. For example, the Gain block does not write out an initial output value in its Block Start method. Whether to write out an initial output value in the Block Start method is pre-determined by individual blocks. The predetermined initialization of the conventional mechanism has the following problems.
Initial Condition Leakage
If an Enabled Subsystem block includes a Constant block, the Constant block writes out an initial output value in its Block Start method (which is part of initialization) even before the Enabled Subsystem block is enabled. This initial value is seen from the outside of the Enabled Subsystem block, such as a Scope block coupled to the Enabled Subsystem block. The conventional initialization mechanism therefore results in an initial condition leakage.
Unnecessary Initialization
If the output port of a Constant block is coupled to the input port of a Gain block, the Constant block does not need to write out its initial output value in its Block Start method because the output value of the Constant block is not needed until the block diagram enters the simulation loop. However, in the conventional initialization mechanism, the Constant block always performs an unnecessary initialization of its output.
Less Optimal Partition of Initialization Tasks
Assuming that Integrator block has an external initial condition (IC) input port and the Integrator block wants to read an IC input value and use this value to initialize the state in its Block Initialize method, as depicted in FIG. 17. In the conventional initialization mechanism, the Block Initialize method does not actually set the initial value for the state, and the state initialization task becomes part of the Block Outputs method called in the simulation loop. This is because the Integrator block does not know whether the source output port of the IC port can write out an initial output value in the Block Start method. Hence it sets a flag to indicate that the IC value needs to be loaded, and postpones the state initialization to the Block Outputs method in the simulation loop. This partition guarantees the state to be initialized with the correct value, but is not optimal. Exemplary code for conventional approach is provided as follows.
Block Start methodvoid MdlStart(void){ rtB_SRC = sysfunction( . . . );}Block Initialize methodvoid MdlInitialize(void){ rtDWork.Disc_Time_Integr_IC_LOADING = true;}Block Outputs methodvoid MdlOutputs(int_T tid){ /* Compute output of SRC block */ rtB_SRC = sys_function( . . . ); /* * If IC has not been loaded, get the output value of SRC block * and load it into Discrete Integrator block's DSTATE as the * IC. Also reset the IC_LOADING flag to false so that loading IC * happens only the first time MdlOutput is called. */ if ( rtDWork.Disc_Time_Integr_IC_LOADING) {  rtDWork.Disc_Time_Integr_DSTATE = rtB_SRC;  rtDWork.Disc_Time_Integr_IC_LOADING = false; } /* Compute output of Discrete Integrator block */ rtB_Disc_Time_Integr = rtDWork.Disc_Time_Integr_DSTATE; /* Compute output of Sine Wave block */ rtB.Sine_Wave = sine_wave_function( . . . ); rtY.Out1 = rtB_Disc_Time_Integr;}Block Update methodvoid MdlUpdate(int_T tid){ rtDWork.Disc_Time_Integr_DSTATE =  rtDWork.Disc_Time_Integr_DSTATE+ rtB.Sine_Wave;}
Less Efficient Simulation
The conventional initialization mechanism requires an extra Boolean flag and an extra if-condition to determine whether it needs to read in the IC port value of the Integrator block and use this value to initialize state of the Integrator block at every simulation step, as shown above in the exemplary code for the conventional approach. In the conventional simulation loop, the Block Outputs method of the block that is feeding the IC port is called at every simulation step, although the input signal of the IC port is needed only when the Integrator block initializes its state.
Less Efficient Code Generation
Furthermore, the conventional initialization mechanism deteriorates the readability of generated code for the Block Outputs method because of the extra code introduced for external IC handling. This problem extends to the accelerator mode simulation that uses the generated code to execute or simulate the block diagram.